Subject: Re: Hello World lives on!
From: [email-masked] (Doug Walker)
Date: Thu, 12 May 1994 13:41:52 GMT
Newsgroups: comp.sys.amiga.programmer

In article <[email-masked]>, [email-masked] (Evan) writes:
|> The following posting is a continuation of a local happening.
|> 
|> 
|> [email-masked] wrote:
|> > This is just a little demo of how to open a screen and a window, then
|> > send some graphical output to it.  It doesn't use any of the window flags
|> > [...]
|> 
|> Here's my two cents worth:  I decided to make it as small as possible
|> without dropping to assembly - with the following results.
|> 
|> Intui_Hello.c     A modified version of Jayson's "HelloWorld.intuition.c"
|>                   This gave me a reduced executable size of 2360 bytes.
|> 
|> Intui_Hello3.c    A rewrite using NOSTARTUP.  This reduced the executable
|>                   a further 900 bytes or so.  But about 600 bytes of c.o or
|>                   sc.lib was still getting linked into the executable and
|>                   of course not used.  So I cut it out with a hex editor:-)
|> 
|> Intui_Hello3.exe  Size, 884 bytes.  Only run from shell!!!
|>                   Compiled with SAS/C 6.51
|> 
|> SCOPTIONS         The option file used to compile Intui_Hello3.c
|>                   To use with "Intui_Hello.c" just remove NOSTARTUP
|> 
|> 
|> PS: The chunk of executable I removed was auto-lib-init code.  Is it the
|> norm for SAS/C to add it in no matter what, or have I missed something?
|> 

SAS/C won't link in anything that you don't tell it to.  I tried your code
with the MAP MAPHUNK MAPXREF options, and discovered that you were linking in
autoinit code for the Intuition, Graphics, and DOS libraries (even though it
was never called).  Why?  Because you weren't declaring IntuitionBase,
GfxBase, and DOSBase.  Instead, you pulled their definitions in from the
library.

If you pull them in from the library, you also get the autoinit code.

Moral: If you're not using a startup that calls __fpinit() and __fpterm(),
make sure to define all your library bases explicitly.

(By the way, I got your example down to 748 bytes by defining those library
bases.)

Here's detail on how to figure this out.  The linker map file is VERY 
useful when you want to figure out how to get rid of unneeded stuff, BTW.

I compiled with MAP MAPHUNK MAPXREF and some formatting options and got 
this map file:

=====================
4 09:23:Page 1-1

 num hunk         size filename         punit            type         base  alv     size
   0 text          4b4 Intui_Hello3.o   Intui_Hello3.c   code            0    0      264
                       LIB:sc.lib       _construct.c     code          264    0       34
                       LIB:sc.lib       dummy.c          code          298    0        4
                       LIB:sc.lib       autoopenfail.c   code          29c    0       fc
                       LIB:sc.lib       doslib.c         code          398    0       5c
                       LIB:sc.lib       gfxlib.c         code          3f4    0       60
                       LIB:sc.lib       intuitlib.c      code          454    0       60
   1 __MERGED       90 Intui_Hello3.o   Intui_Hello3.c   data            0    0       30
                       T:3JQM5.0000     _ctdt.o          data           30    0       24
                       LIB:sc.lib       _construct.c     data           54    0        4
                       LIB:sc.lib       _stdwin.c        data           58    0       14
                       LIB:sc.lib       wbmsg.c          bss            6c    0        4
                       LIB:sc.lib       _construct.c     bss            70    0        4
                       LIB:sc.lib       oslibversion.c   bss            74    0        4
                       LIB:sc.lib       doslib.c         bss            78    0        8
                       LIB:sc.lib       gfxlib.c         bss            80    0        8
                       LIB:sc.lib       intuitlib.c      bss            88    0        8

4 09:23:Page 3-1

symbol                   (Def) Module  Off
@__autoopenfail  autoopenfail.c          0 intuitlib.c            22
                                           gfxlib.c               22
                                           doslib.c               22
_DOSBase         doslib.c                0 Intui_Hello3.c         1c
                                           Intui_Hello3.c         bc
                                           Intui_Hello3.c        100
_GfxBase         gfxlib.c                0 Intui_Hello3.c         40
                                           Intui_Hello3.c         8c
                                           Intui_Hello3.c         e0
_IntuitionBase   intuitlib.c             0 Intui_Hello3.c         2e
                                           Intui_Hello3.c         4c
                                           Intui_Hello3.c         c6
                                           Intui_Hello3.c         d4
                                           Intui_Hello3.c         f0
_LinkerDB              (0:*)               Intui_Hello3.c          6
__STD_110_closed doslib.c               3a _ctdt.o                14
__STD_110_closeg gfxlib.c               40 _ctdt.o                1c
__STD_110_closei intuitlib.c            40 _ctdt.o                18
__STI_110_opendo doslib.c                0 _ctdt.o                 c
__STI_110_opengf gfxlib.c                0 _ctdt.o                 4
__STI_110_openin intuitlib.c             0 _ctdt.o                 8
__WBenchMsg      wbmsg.c                 0 autoopenfail.c         1c
                                           autoopenfail.c         98
___construct     _construct.c            0 _ctdt.o                 0
___ctors         _ctdt.o                 4 _construct.c            0
___oslibversion  oslibversion.c          0 intuitlib.c             8
                                           gfxlib.c                8
                                           doslib.c                8
                                           autoopenfail.c         46
___stdiowin      _stdwin.c               0 autoopenfail.c         2a
=====================

(Note: In the XRef section (page 2), column 1 is the name of the symbol
being defined; column 2 is the name of the module it is defined in;
column 3 is the offset within that module; and the other module-offset
pairs are the locations that refer to the symbol.)

One thing that jumps out right away from looking at the Xref section is the 
autoinit and autoterm routines (the ones starting with __STD and __STI).
We don't need 'em, we don't want 'em, let's get rid of 'em.  The Xref 
section tells us they are defined in doslib.c, gfxlib.c, and intuitlib.c.
These are files in sc.lib.  What are these files doing in our program?
Time to go back to the Xref.

Other than the _STD and _STI routines, the only stuff defined in these
three files are _DOSBase, _GfxBase, and _IntuitionBase.  These symbols
are referred to from Intui_Hello3.c in several places.  Therefore,
the linker pulled in doslib.c, gfxlib.c, and intuitlib.c in order to
satisfy those references, and got the _STD and _STI routines because
they were in the same module.

OK, so far so good.  The logical leap that you have to make is to accept
the fact that the linker does some "magic".  If the linker sees at least
one _STI or _STD routine, it creates and links in a file called _ctdt.o,
which contains setup information that allows the startup to work on
autoinit/autoterm routines.  As you can see from the Xref, almost everything
else linked in was linked in because _ctdt.o was there.  Therefore, if you
get rid of the _STI and _STD routines, you're home free.

I declared these three library bases in the .c file and the executable turned
out to be 748 bytes, and produced this map:

=====================
4 09:34:Page 1-1

 num hunk         size filename         punit            type         base  alv     size
   0 text          248 intui_hello4.o   intui_hello4.c   code            0    0      244
                       LIB:sc.lib       dummy.c          code          244    0        4
   1 __MERGED       5c intui_hello4.o   intui_hello4.c   data            0    0       50
                       intui_hello4.o   intui_hello4.c   bss            50    0        c

4 09:34:Page 3-1

symbol                   (Def) Module  Off
_LinkerDB              (0:*)               intui_hello4.c          6

=====================

MUCH better!  As you can see, all symbols are now defined in intui_hello4.c except
for one pulled in from dummy.c in sc.lib.  This symbol turns out to be the dummy
version of __chkabort that gets pulled in because you specified the NOCHKABORT
option.  It's only 4 bytes, and you're not going to do any better in your code,
so there's no point in worrying about this one.  _LinkerDB is a linker-defined
symbol used by the startup code to locate the beginning of external data, so
there's nothing you can do about that one either.  This is as good as it will
get without tinkering with the actual program's algorithm.

-- 
  *****                    / [email-masked]
 *|_o_o|\\     Doug Walker<  BIX, Portal: djwalker
 *|. o.| ||                \ CompuServe: 71165,2274
  | o  |//     
  ====== 
Any opinions expressed are mine, not those of SAS Institute, Inc.